In an object oriented processing system based on an object oriented language such as Java, C++ and the like, an “application” is a collection of one or more instances of objects that perform a specific function or task and an application “instance” is one specific and independent case or request for an application's functions comprising one set of the application's object instances typically running in an assigned thread of execution. Data can be passed from one object to another object within an application via arguments to methods associated with the individual objects that comprise the application. This method of data passing has the difficult requirement that cooperating objects have advance knowledge of all the data that a called object will need, as well as all the data that will be needed by any object that works with the called object.
Another method for sharing data among objects in an object oriented processing system is the Java InfoBus API. The InfoBus API facilitates data communication between objects cooperating in the same Java Virtual Machine (JVM). Using the notion of a “bus,” the InfoBus API allows objects that implement it to “plug into” the bus. Any “plugged in” member of the bus can exchange information with any other member in a structured way. The downside of sharing data through the InfoBus API is the lack of data persistence and the limitation to the single JVM. Because the bus structure does not retain the data after its transmission, the data cannot be referenced at some later time.
Still another method for providing data to remote objects (i.e. objects not called directly) is to place them in a shared location. By way of example, in a Java-based object oriented processing system, the JVM executes the series of objects that comprise one or more Java applications. A static hash table can be defined that allows the application objects to store and retrieve data using hash table “key” identifiers. Defining a static hash table to provide for storage and retrieval of data is desirable because the key identifiers and values of key identifiers are unknown to objects at compile time. This method works well when only one instance of the application is running in the JVM. However, it is often desirable to run multiple instances of an application simultaneously in multiple thread groups. For example, running multiple instances of an application simultaneously in an object oriented environment can be used to advantage in a telephone call center. Multiple incoming calls at the call center require simultaneous processing. This processing can be implemented by spawning new application instances as new calls arrive. The processing of multiple calls thus results in the simultaneous execution of multiple instances of the same application. A problem arises relative to data sharing in this situation, because each application instance cannot have its own static hash table. A static hash table is a “class” variable such that only one such table can reside within the JVM. Nor can multiple instances of an application running within a single JVM use the same static hash table to store local copies of data. Each application may require the placement of different information in the hash table, and this can lead to data collisions.
In enterprise wide systems, there is a need to add or update data and services and to notify collaborating applications of the change. In addition, such global information needs to be persistent to survive application fail-over. However, implementation of such features is complex, frequently requires third party products, and can adversely affect system availability.
Existing systems typically use a startup class or script that is called when the service is started to load configuration parameters that need to be shared by multiple applications running in the server. However, this approach requires that the server be restarted whenever configuration parameters are changed. This in turn results in system outage that may not be tolerable from an operational perspective.
Alternatively, parameters can be loaded in a deployment descriptor of a designated application and then shared programmatically by the application. To change a parameter, the deployment descriptor needs to be modified, the applications need to be built, regression tested, and deployed. Accordingly, there is inherent risk in this approach that errors will be introduced. In addition, significant resources are required in order to implement a changed parameter. This technique is also limited because the change is not propagated outside the application.
Applications often use services that are updated periodically. For example, services may be updated to include new software patches, agents, libraries, etc. In order to implement new services or service releases, an application must be repackaged and redeployed. This necessarily involves application downtime. Accordingly, system availability is impacted.
There frequently is a need to communicate an event to all collaborating applications, whether those applications are local or distributed. For example, distributed collaborating applications need to know when a user logs off so they can perform clean up activities such as closing product connections, terminating processes, and releasing resources. Typically, there is no inherent mechanism to notify collaborating applications of an event. Notifications can be performed via messaging or RMI techniques, but these increase application and deployment complexity. For messaging, third party products have also been required.
In connection with distributed computing, a task, for example solving an n-dimensional equation, may be divided between multiple applications hosted on different parts of the network, and each application may access to unique pieces of information. Applications may need to communicate to solve the equation collaboratively with possible processing order dependencies. New applications may need to be introduced in connection with additional available information or processing. In a typical distributed computing system, a controller manages workflow. Communication mechanisms between applications include messaging, RMI, SOAP, and SMTP. If the work flow changes, the controller application needs to be modified. This requires development, test, and deployment effort. In addition, system availability may be impacted.
Although systems for supporting data sharing between applications and application instances have been developed, such systems have typically been incapable of providing updated data to applications without impacting availability. In addition, systems have lacked change notification with respect to internal and external data sources. Although other systems have used persistence techniques, they typically do not address efficient communication of changed data to applications. Other systems allow services to be shared through registration and discovery. However, such registration and discovery processes can require significant resources.